Diskussion:Rekursiver Abstieg

In der derzeitigen Fassung ist der Artikel vollkommen unbrauchbar. Er müsste dringend erweitert werden. Als Vorlage kann der gute englischsprachige Artikel dienen. Leider kann ich selber zu dem Thema nicht viel schreiben. --89.54.67.59 13:38, 22. Mär 2006 (CET)

Ich habe mal angefangen. Was m.E. noch fehlt, ist ein Beispiel, z.B. das aus dem englischsprachigen Artikel. Wer weiß, wie man das Beispiel übernimmt und dabei die Versionsgeschichte intakt lässt (um sich nicht mit fremden Federn zu schmücken), möge das gern tun. Vielleicht sollte man dann meinen Pseudocode durch C ersetzen. -- UKoch 23:39, 8. Apr. 2011 (CEST)

Noch besser wäre m.E. das Beispiel aus LL(k)-Grammatik, das so in Aho/Sethi/Ullman (1988) steht. Wenn mir niemand zuvorkommt, schreibe ich was dazu und zu EBNF. -- UKoch 17:17, 12. Apr. 2011 (CEST)

Follow-Mengen

Die Follow Menge muss nur beruecksichtigt werden, wenn a_i nullable ist. Sie kann natuerlich trotzdem verwendet werden, macht es aber nur unnoetigt kompliziert. (nicht signierter Beitrag von 94.139.19.128 (Diskussion) 10:36, 23. Okt. 2011 (CEST)) (Ich habe diesen Beitrag hierhin verschoben, wo er besser aufgehoben ist als mitten in einer anderen Diskussion. -- UKoch 18:49, 25. Okt. 2011 (CEST))

Toll, endlich noch jemand, der sich für Compilerbau interessiert und Ahnung davon hat! Ich hatte die Hoffnung schon aufgegeben. -- Zur Frage: "Nur wenn alpha_i nullbar" stimmt natürlich, steht auch so im Artikel. Aber was wäre denn ein Beispiel "aus dem echten Leben", das ohne Epsilon-Regeln, sogar allgemein ohne nullbare Symbole, auskäme? -- UKoch 18:49, 25. Okt. 2011 (CEST)

LL(k)

Im ersten Abschnitt wird behauptet: Voraussetzung ist eine LL(k)-Grammatik für die zu parsende Sprache. Im Folgenden wird der häufige Fall $k=1$ angenommen.

Das ist falsch. Es ist auch möglich einen rücksetzenden rekursiven Abstiegsparser zu entwickeln. Dem muss keine LL(k)-Grammatik zugrunde liegen. (Auch wenn der dann nicht zwangsläufig deterministisch ist)

Python-Beispiel verwendet zu viele Tricks

Der Code soll ja das Prinzip des Parsens und Evaluierens erläutern. Wenn zu viele Konstrukte von Python verwendet werden, die verschleiern wie es eigentlich geht, hat das wenig Sinn.

Folgender Code ist z.B. sehr schlechter Stil, nicht nur für ein Beispiel, weil viel zu viel in einer Zeile passiert ohne jede Erklärung.

  def evaluate(t):
      if isinstance(t,int):
          return t
      else:
          return dispatch[t[0]](*map(evaluate,t[1:]))

Es fehlt auch jede Erläuterung dazu wie der AST in Python erstellt wird.

Die C und Pascal-Beispiele auf der englischen Wikipedia sind deutlich klarer, weil der verwendete Code weniger kompakt ist und die Schritte explizit sind. (nicht signierter Beitrag von 88.219.179.109 (Diskussion) 22:06, 5. Mär. 2020 (CET))